home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000125_owner-urn-ietf _Wed Oct 30 14:03:37 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  4KB

  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA03163 for urn-ietf-out; Wed, 30 Oct 1996 14:03:37 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA03158 for <urn-ietf@services.bunyip.com>; Wed, 30 Oct 1996 14:03:35 -0500
  3. Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA16156  (mail destined for urn-ietf@services.bunyip.com); Wed, 30 Oct 96 14:03:33 -0500
  5. Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id MAA10126; Wed, 30 Oct 1996 12:58:47 -0600 (CST)
  6. Date: Wed, 30 Oct 1996 12:58:47 -0600 (CST)
  7. From: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  8. Message-Id: <199610301858.MAA10126@ncsa.uiuc.edu>
  9. To: Larry Masinter <masinter@parc.xerox.com>
  10. Cc: urn-ietf@bunyip.com
  11. Subject: Re: [URN] What is equivalence?
  12. In-Reply-To: <96Oct23.004640pdt."2763"@golden.parc.xerox.com>
  13. References: <v03007812ae936118dd1b@[192.71.220.137]>
  14.     <96Oct23.004640pdt."2763"@golden.parc.xerox.com>
  15. Sender: owner-urn-ietf@services.bunyip.com
  16. Precedence: bulk
  17. Reply-To: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  18. Errors-To: owner-urn-ietf@bunyip.com
  19.  
  20. Larry Masinter writes:
  21.  > Do the namespaces 'define' equivalence, or do they 'implement' it?
  22.  > 
  23.  > That is, would you want to assert that if
  24.  >    isbn:0-13-443672-5 and isbn:013443672-5 
  25.  > are ever to be treated the 'same', then they must always be treated
  26.  > the 'same'? Otherwise, a client which has 'knowledge about the
  27.  > namespace' might find that knowledge out of date.
  28.  
  29. I don't recall if anyone mentioned the idea of a client
  30. getting and caching general rules (e.g. regular expressions) for how
  31. to transform an identifier into a canonical, preferred form.
  32. Testing equivalence would then involve transforming all identifiers
  33. to cannonical form, and then comparing.
  34.  
  35. One resolution service might be to answer a request for the canonical
  36. form of an identifier, perhaps along with the rule used to do the
  37. transformation.
  38.  
  39.  > On the other hand, you might want to allow 
  40.  >     duns:ibm to be the same as duns:international-business-machines
  41.  > but are you willing to allow that equivalence to be cached in clients
  42.  > or wired into them?
  43.  
  44. I gather the idea here is that "duns:ibm" is a prefix for a whole class
  45. of identifiers.
  46.  
  47. Mapping 'duns:ibm' to 'duns:international-business-machines' (or vise
  48. versa) goes beyond a few general transformation rules to lots of
  49. specific cases (one for every company name with an acronym), but
  50. clients could and should certainly cache as many such specific
  51. rules as are useful, and still valid.
  52.  
  53. But there is another notion of equivalence that should be considered:
  54. the equivalence of any two identifiers may be specified by a naming
  55. authority (or an associated resolution service).  The identifiers may
  56. be in completely different name spaces, so some agreement must exist
  57. and be certifiable.  This equivalence of two identifiers that applies
  58. to only these specific identifiers is a special case of the general
  59. transformation rule.
  60.  
  61. In all cases, the identifier space (or some subauthority within it)
  62. specifies how equivalence is determined, either as a very general rule
  63. or as lots of specific rules.  A few very general rules with very long
  64. life times may be wired into clients.
  65.  
  66. --
  67. Daniel LaLiberte (liberte@ncsa.uiuc.edu)
  68. National Center for Supercomputing Applications
  69. http://union.ncsa.uiuc.edu/~liberte/
  70.